|
|
| Author |
Thread Statistics | Show CCP posts - 11 post(s) |
Dan Hour
Ghost Fleet.
0
   |
Posted - 2012.11.20 06:04:00 -
[1] - Quote
Is the api going be using Oauth 2.0, and is it going to be RESTful with correct verbs or are we going to be doing nothing but gets with a huge query strings.... sorry pent up rage of nothing gets for a "RESTful" are spilling out.
Also choosing between json and xml would be nice, or do we have that already?
|
Dan Hour
Ghost Fleet.
0
|
Posted - 2012.11.21 00:34:00 -
[2] - Quote
Not in the first iteration of the API but are you guys considering something other than rest as well? Say something with websockets. If the API connects to the in game chat at all it would be very cool. However last time i checked Nginx did not have much support for websockets proxies. (Insert plug for xmpp with json). |
Dan Hour
Ghost Fleet.
0
|
Posted - 2012.11.21 17:42:00 -
[3] - Quote
I can settle for that, but how about that chat part? Granted I've never given the in game chat system much thought about how it was implemented, but anyway I'm 99.9% positive the PS3 talks xmpp. I'd really like too do something like an irc/xmpp protocol bridge with the in game chat. It's been a while since i watched that fanfest (I think it was fanfest) video about CREST. So is chat something thats within the scope of CREST, can you say? Or what isn't within the scope of crest? Sorry if I'm asking something here that was already answered... |
Dan Hour
Ghost Fleet.
0
|
Posted - 2012.11.22 08:21:00 -
[4] - Quote
Liu Ellens wrote:
I don't know the Twitter stream and also couldn't find (didn't look far for) the protocol definition for your stream.
here is a link to twitter doc for their streaming api: https://dev.twitter.com/docs/streaming-apis
You can kind of think of it as a tcp connection that remains open and the server will write http down the pipe.
I would imagine that they wont implement Server sent events as that is mainly a browser thing, what i mean by that is that the browser is responsible for the connection and not your code, so while it could be an elegant solution it is limited in that way. Plus it does stuff with dom events?? No one likes dom.... |
Dan Hour
Ghost Fleet.
0
|
Posted - 2012.11.22 21:02:00 -
[5] - Quote
I see what you mean now, have you done much work Server Sent Events? I personally have never touched them, even though all the work i do is "real time" Server Sent events have just never fit the bill. By that I mean all the talking between client and server is too bi-directional. I had mentioned websockets early in the thread because you can send information both ways, faster and with less overhead than making lots of rest calls. Where server sent events is just server to client and is more limited to browser (please correct me if I'm wrong about that).
The point that I'm getting at with the Server Sent Events is that they are limiting the clients to the browser (again correct me if im wrong about that), where with CREST api your "clients" maybe other applications. There would be a security concern if you are making direct CREST api calls from your browser. The user after they got their Oauth token could then make any CREST call that YOUR developer key could use. Leaving your application open for unintended abuse.
I believe the intended architechure is:
YourClient <---> Your App <---> CREST api and not Your APP ---> Your Client ---> CREST api
but now im starting to ramble and have drifted away from server sent events
TL;DR: ramble ramble use case for websockets = chat, use case server sent events? market data maybe? but that seems more like PubSub (*cough* websockets)territory.... oh boy must stop rambling. |
Dan Hour
Ghost Fleet.
0
|
Posted - 2012.11.22 21:30:00 -
[6] - Quote
Steve Ronuken wrote:Kinda yes, kinda no.
To what exactly are you referring, in the abuse case what i mean is if you are make CREST api calls from javascript then you as a developer have lost control what calls are being made by Your application with the developer agreement, what ever it may be. And to me that would be a massive mistake. Allowing your web base client to make calls to the crest api is too open to abuse, and create more spots for security problems.
Im assuming that the CREST api agreement will before YOUR appilcation, so if you move those calls to the api to client without having to go through your app then you are leaving yourself open to having ccp shutdown you access to the api because some **** decided to make a ton of calls before the oauth token expires
Yes i agree your application should make calls or your users be haft that is not the security point i was making. |
Dan Hour
Ghost Fleet.
0
|
Posted - 2012.11.23 08:17:00 -
[7] - Quote
Yes cool thanks for confirming that nginx still does not support websockets, I knew that was the case awhile ago and mentioned in an earlier post. While I would love them to use websockets I'm defiantly not expecting them in when they first launch CREST. Also thank you for the clarification on Server Sent events, like i said i have never used them so I don't claim know much about them. Why I'm so heart set on WebSockets is because I'm hoping the in-game chat will someday be in the scope of CREST, and WebSockets are a two way pipe.... All of my programing experience has been in "real time" so I'm just bitter and don't want to do any kind of long polling.
and I will be more than willing to give any CREST using web app a free one day pen test if they are ok with it!
EDIT: Nginx has plans to add web socket support as well? I think... going to ask google now
EDIT2: Nginx is plan to support websockets in version 1.3.x |
|
|
| |
|